boot hack

Beaucoup d’éléments restent flous.

Tu parles de clé USB, tu veux dire carte SD ou alors tu utilises aussi un Dongle USB ? Je suppose que c’est bien la SD.

Ensuite, tu as tout supprimé sur ta SD. Tu peux toujours refaire une préparation de cette dernière via le site SDSetup pour y remettre tous les éléments du hack et outils nécessaires. Il te faudra ajouter les sigpatches manuellement.
Voici le tutoriel pour toutes les infos:
https://gamergen.com/forums/underground ... 36600.html

Il te faudra aussi dumper les clés via Lockpick_RCM une fois que tu auras résolu le reste:
https://gamergen.com/forums/underground ... 56353.html

Au delà de ceci, il faudrait savoir si sur ta console, le format exFat est bien actif et que le driver est bien installé car si ce n’est pas le cas, ce sera en FAT32 qu’il faudra formater ta SD. A l’issu, tu auras un message sur ta console pour la mettre à jour. Cela installera le driver exFat si ce n’était pas déjà fait. Tu pourras formater ta SD en exFat ensuite. Et si le format exFat est déjà actif, alors ta SD doit l’être également.

Ceci était pour les aspects underground !

Pour ce qui concerne ta console et le côté hardware. Si cela concerne ta batterie, le fait de la décharger complètement et de tirer dessus avec insistance n’est pas trop conseillé. Ensuite, il y aussi le mode autoRCM qui a tendance à drainer la batterie et si on oublie de la charger, cela devient complexe mais tu n’en parles pas dans ta description donc je suppose que tu ne l’as pas activé avec le hack.

Maintenant si la batterie se recharge, c’est qu’elle n’est pas en cause. Et pour ce qui est du mode autoRCM, le boot sur le CFW se fait sans le JiG si tu l’as activé.

Si la console atterrit sur un écran noir au démarrage, pour vérifier si elle est en mode RCM, il te faut la relier au PC et si tu entends un son, c’est le cas. Il faut préalablement avoir installé le driver via TegraRCMGUi. Le driver du mode RCM et de la console ne sont pas les mêmes.

Et si un hard reboot min 12s n’aboutît pas, soit il y a un problème hardware sur la console, soit il y a ce que j’indique juste avant.

De moi, les messages que tu as eu, sont dûs, dans un premier temps, aux outils underground sur la SD. Les erreurs avec fusee-secondary et Missing LP0 <sleep mode> lib! Missing or old Minerva lib! , Update bootloader folder! sont liées à Hekate. Donc soit il s’agit d’une mise à jour non faite pour la dernière version HOS 13.2.0 ou alors il s’agit d’une mise à jour des outils pour une version de HOS antérieure à la 12.0.0. A voir car tu n’indiques pas ta version de firmware.

Tu as aussi le script de Shadow qui pourra t’apporter une aide pour certains aspects. Mais difficile de savoir car qui pas devant ta console.
https://gamergen.com/forums/underground ... 44252.html

Une source inconnue et peu fiable. Pourquoi enlever le mode RCM pour commencer alors que ce mode s’il doit être enlevé est le mode autoRCM. Mais même au delà de cette erreur d’intitulé, si tu l’avais activé avant, et que tu l’as désactivé ensuite, alors c’est le cas. En revanche, s’il n’était pas activé avant et que tu l’as désactivé, alors tu n’as fait que l’activer. Cela semble plus logique.

Et s’il est bien activé comme je le suppose, alors ta console attend juste de booter sans le JiG en injectant un payload, soit fusée, soit Hekate, via PC si c’est le moyen que tu utilisais depuis. Donc soit le driver n’est pas installé sur ton OC. Et quand je parle de driver, il s’agit de celui du mode RCM et non de la console en mode normal. Et cela s’opère via TegraRCMGui comme déjà dit.

Au delà de cela, il ne faudrait pas qu’en faisant cela, tu es fait une manipulation irréversible. Si le mode autoRCM n’était pas actif avant cette opération, il n’y avait pas de raison de procéder ainsi.

Si la console ne répond plus, soit la batterie a pris un coup, soit tu as corrompu le boot0 de la console. Si tu es certain d’avoir mis à jour tous les éléments sur ta SD avec notamment les derniers sigpatches, et que ce mode autoRCM est bien actif comme je le suppose, la console attend un boot sans le JiG. En revanche, si cela concerne la batterie, ce sera forcément un changement si elle ne charge pas. Et si c’est le boot0, il faut le restaurer avec une sauvegarde que tu possèdes mais il faut un accès à la console sauf erreur ou des moyens tiers sans cela.

Suivre des tutoriels dont la source n’est pas officiel amène à des difficultés irréversibles le plus souvent. Et utiliser des packs tout fait causent plus de problèmes qu’autre chose.

A tout hasard, pour vérifier si tu as tout bien fait et aussi répondre à tes questions, voici le tutoriel qui se base sur des sources officielles:
https://gamergen.com/forums/underground ... 36600.html

Et voici celui qui concerne DayBreak
https://gamergen.com/forums/underground ... 62975.html

Et pour essayer de te sortir de cela, tu as également le script de Shadow qui propose un certain nombre de fonctions.
https://gamergen.com/forums/underground ... 44252.html

Dans tous les cas, et comme dis depuis le début, soit ta console attend de booter, soit c’est ta batterie, soit c’est une corruption de données. A voir.

Bonjour,
Ma switch actuellement:
sysnand 9.2.0 / emunand 11.0.0 créée via SX OS

De peur de faire bétise, je voudrais garder sysnand 9.2.0 et mon SX OS tel quel sur la carte SD

Avec une 2eme carte SD, est-il possible de créer un hack complet en emunand 13.2.1 sous Atmosphère ?

Ainsi avec la seul contrainte de changer la carte SD, j'aurais en sorte un dual-boot SX OS et Atmosphère

Si rien n'est enregistrer dans les mémoires de la console au moment du hack (comme je l'ai compris), ça doit fonctionner, non ?
L'avantage pour moi étant de conservé SX OS opérationnel (avec jeux et sauvegarde) et de découvrir tranquillement Atmosphère avec les jeux nécessitant system 13.2.1

Si en démarrant ta console normalement, tu n’as aucun problème, le problème se situerait donc au niveau de la SD ou son lecteur ou de la préparation de ta SD.

Si la console ne boot pas sur le CFW, soit il manque des éléments sur ta SD, soit le lecteur de carte est défectueux (une autre piste hardware qui peut se vérifier en démarrant normalement HOS). Je dis cela car tu as changé de SD entre temps. Le lecteur de carte est fragile et retirer trop souvent la SD peut le détériorer si on ne fait pas attention. Toutefois, si en étant dans HOS, l'accès se fait, pas de raison et cela rejoint donc une mauvaise préparation.

Le tutoriel pour le hack avec l’ensemble Des démarches:
https://gamergen.com/forums/underground ... 36600.html

Bien que sur l’autre console, tout fonctionne, cela ne signifie pas qu’une mauvaise manipulation n’est pas à l’origine du problème rencontré sur l’autre. De plus, l’erreur indique que le payload n’a pu être injecté donc le câble serait aussi une cause.

Lors de la préparation de la SD, prendre les derniers outils et ne pas oublier d’ajouter les sigpatches manuellement.

Des pistes à vérifier...

Le redémarrage de la console implique de reinjecter le bin pour booter. Il s’agit d’un hack non permanent donc lorsque la console redémarre, le hack n’est plus opérationnel.

Pour sauvegarder la NAND, hekate reste l’outil facile et utile.

Les backups, une fois, installé sur l’emuNAND, ne sont pas à réinstaller si la console redémarre. En revanche, pour les utiliser, il faut boot en CFW, cela va de soi.

Pas testé de booter SX OS sans l'Emunand.
Etant donné que j'ai pas mal "laché" le suivi du Hack Switch, il n'y a pas de risque à ce que je boot sur ma Sysnand qui doit être très bas en version.
Donc si je comprend bien, si cela fonctionne sur ma sysnand, il me faudra supprimer mon emunand et la créer de nouveau puis une fois recréer, pensér à UP de nouveau mon emunand avec Choix du jour ?

PS : je sors un peu de ce sujet, mais aurai tu un tuto pour booter depuis le menu de SX OS sur Atmosphere ou autre ??

En aucune manière, connecter sa console online depuis l’emuNAND est conseillée. D’ailleurs, le tutoriel donné en lien l’explicite bien et précise bien de paramétrer des DNS pour éviter cela. Et il existe aussi d’autres solutions précisées en FAQ qu’il faut lire dans son ensemble.

De plus, connecter sa console online depuis la sysNAND n’est pas non plus conseillé mais cela se fait, si et seulement si, on est certain que les données underground n’ont transitée que sur l’emuNAND. Ceci est le conseil donné pour réduire fortement les risques de ban.

Il n’existe aucun moyen de debannir une console. Il n’y a aucun outil qui le permet à ce jour. Seul la console est bannie mais pas le compte Nintendo.

Cela est fortement dommage de ne pas prendre le temps de lire pour éviter de se retrouver dans cette situation. Personne ne peut confirmer ce qui est envoyé réellement en termes de télémétrie à Nintendo mais le fait de créer une emuNAND et de paramétrer les DNS évite déjà fortement le ban. S’ajoute à cela d’autres outils qui s'utilisent en complément. Tout cela est abordé dans le tutoriel.

L’emuNAND est la NAND système emulée sur la SD et la sysNAND est la NAND système sur la console. Les deux sont déliées d’où le fait d’en créer une pour se prémunir d’un ban ou d’un brick. Les données underground sont à utiliser sur l’emuNAND et elle ne doit absolument pas être connectée aux serveurs de Nintendo. Pour ce qui est de la sysNAND, elle s’utilise en officiel en mode normal sans hack actif d’où le fait de redémarrer la console pour être sur HOS sans hack.

Hekate permet trois modes de boot (et plus si on le souhaite) mais il utilise un bootloader non officiel qui n’est pas celui de Nintendo donc si la console est démarrée en mode stock, ce n’est pas avec le bootloader de Nintendo d’où le fait de redémarrer sa console si l’on souhaite utiliser sa syNAND en officiel.

Ce qui modifie la NAND, c’est l’utilisation de NSP, du mode autoRCM ou de certains homebrews. C’est pour cela qu’il faut utiliser l’emuNAND. La sysNAND servira pour des jeux legits et le online si et seulement si elle n’est pas modifiée comme indiqué juste avant. Quant à l’emuNAND, elle doit être configurée de telle manière à éviter une connexion aux serveurs. C’est pourtant la base des indications données et à suivre.

Et pour répondre à la dernière question, il existe cela mais qui a ses limites:
https://gamergen.com/forums/underground ... 39686.html
Le online officiel, pour ta console, est terminé.

1. Une console hack avec un accès online sans protection peut engendrer un ban mais seul le temps le dira.

2. Le problème réside dans les eFuses de la CM que tu as grillés et ceux du port cartouche nommés eFuses LOTUS, également. Tu auras donc une erreur en mode HOS normal. Le patch NoGC permet de contourner cela mais implique de tout le temps démarrer en mode CFW. Et si ta Switch n’est pas patchée, je ne vois pas l’intérêt de rester en 4.1.0 et de continuer à utiliser SX OS. Il ne te reste plus qu’à engager la démarche avec AMS/Hekate et de rendre compatible ton emuNAND pour les deux hack.
Toutes les infos dans ce tutoriel:
https://gamergen.com/forums/underground ... 36600.html
SX OS n’est plus maintenu à jour et ne prend en charge que la version HOS 11.0.0 et inférieure. Toutefois, si l’emuNAND est toujours en 11.0.0, tu peux malgré tout y accéder via le Menu de SX OS sur ta sysNAND. Pas de raison que non car l'accès au Menu est différent du boot. En revanche, comme dit plus haut, ton port cartouche sera inutilisable sur ton emuNAND car tu as grillé ses eFuses LOTUS. Aucun moyen de contourner cela sur SX OS.

3. JKSV est opérationnel. Il doit te manquer un aspect dans la démarche.
https://gamergen.com/forums/underground ... 57058.html

4. Le XCi s’installe comme un NSP.